NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/6572

Internet Message Format | 1996-08-05 | 3.7 KB

Path: rcp6.elan.af.mil!rscernix!danpop
From: [e-mail] (Dan Pop)
Newsgroups: comp.lang.c
Subject: Re: What to do when feof() is NOT feof()
Date: 19 Feb 96 16:09:16 GMT
Organization: CERN European Lab for Particle Physics
Message-ID: <danpop.824746156@rscernix>
References: <4g7rsj$[e-mail]> <[e-mail]> <4g9tph$[e-mail]>
NNTP-Posting-Host: ues5.cern.ch
X-Newsreader: NN version 6.5.0 #7 (NOV)

In <4g9tph$[e-mail]> [e-mail] (Aubrey Harrison) writes:

>Once again, the original message did not indicate what OS or compiler the
>person was using. I should have been clearer in my response that I was
>referring to MS-DOS and Microsoft C.

But you haven't.  And this is the point: you phrased your answer as if it
were describing a general C feature, not an implementation detail on a
certain platform.  The unsuspecting beginner reading your original post
would be led to believe that this is how C works, and this is false.

>I only responded because I have had the
>exact same problem and tracked it down to the fact that while the file I was
>reading was a "text" file there were a few bytes (including ascii 26) that were
>killing fgets and signalling end-of-file when it was not.

This behaviour is allowed by the standard whenever a non-printable
character (other than horizontal tab and newline) is read from a text
stream.

>Maybe he has some
>other problem, maybe he has the same problem. I don't know, and you don't know.

This is precisely why you should have mentioned, as clearly as possible,
that your advice applies ONLY to a certain platform (or set of platforms,
the ^Z convention is inherited by MSDOS from CP/M-80, which actually
_needed_ an end-of-file marker for text files).

Another point is that C doesn't give you the licence to open a file in
whatever mode you want.  If the file was created with the "w" mode, it
has to be opened with the "r" mode.  Likewise, "wb" requires "rb".
On many platforms, you can open the file with the 'wrong' mode and be able
to access its contents (or part of it) with or without alterations, but
the limitations of such an advice have also to be clearly stated.

>I think the notion that the only help that could or should ever be given is an
>exact diagnoses and cure to a problem is a little ridiculous and unpractical.

It's neither ridiculous nor impractical.  If you aren't sure of your
diagnosis and/or solution, let other people who _are_ sure to post.
If the description of the problem is not clear enough (and this was the
case with the post which started this thread), ask for the missing details.

Going ahead and posting a solution based on a set of _implicit_ assumptions
and containing "I think" and "I believe" is below the standards we try to
impose and maintain on this newsgroup.  It's neither ridiculous nor
impractical to ask a responder to check his facts before posting, instead
of using ridiculous disclaimers a la "I'm no expert", "I think", "I believe",
etc.  Most of us aren't experts, either, so we post when we know something
and don't post when we don't know _for sure_.  When the solution is based
on assumptions, because the problem was improperly formulated, these
assumptions have to be clearly stated, preferably before the solution.
This way, the limitations of the solutions will be clear for everybody
and the solution won't have to be amended by other people.

The moral of this thread is that it isn't sufficient to want to be
helpful, good intentions cannot supplement lack of clarity, partial truths
or dead wrong solutions based on personal beliefs.

Dan
--
Dan Pop
CERN, CN Division
Email: [e-mail]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland